Historically, different applications involved in a chip design flow were invoked serially. Each application would read the entire description of a design from one or more files on disk, make changes, and then write the entire design back to disk.
This approach greatly limits the ability for applications to collaborate on incremental changes to the design. For example, often one application is responsible for analyzing the design, while another application is responsible for changing it based on the results of the analysis. For large designs, the overhead of reading and writing the entire design can be substantial compared to the time required to analyze to make small changes or to analyze the effect of those changes. With the serial approach, both applications need to read the entire design. When multiple iterations of analysis and change are required to converge on an acceptable solution, another significant inefficiency arises because both applications start from scratch on each iteration, processing the whole design every time, rather than exploiting information about the incremental series of changes that have been made to process only the parts of the design that are impacted by the changes.
A more recent trend has been to consolidate several applications that need to collaborate into a single monolithic application, and to modify the algorithms previously implemented in separate applications to collaborate incrementally on a single in-memory representation within the monolithic application. This approach offers some advantages over a serial flow, but poses many other challenges. For example when the collaborating applications are from different companies, there can be fundamental business and/or technical obstacles preventing the underlying technologies from being combined into a single application. Even if the collaborating applications are all from the same company, merging technologies can be very time-consuming, and the integration difficulties grow dramatically as the size of the monolithic application increases. A fundamental limitation of the monolithic application approach is that it precludes dividing the problem up into smaller pieces that can be distributed among multiple processors in a server farm.
In one related art, a physical verification system incrementally shares some information about analysis results between a set of distributed processes. In another related art, automated routing software can partition a routing problem among a set of distributed processes, and integrate the resulting routes back into the main representation of the design. However, the implementation is specific to a particular representation of the routing data shared by both the master and slave processes, and that the slave processes operate in a batch mode, returning results only as their task.
With previous approaches based on multiple applications, whenever one application made changes and needed to pass the updated design to another application, the entire design had to be saved to disk by the first application and read by the second application. With previous approaches based on consolidating multiple applications into a monolithic application, it was not possible to distribute the work among multiple processes running on different machines. Therefore, there is a need for an improved method and mechanism to provide a distributed approach.